hack console

De ce que tu expliques, tu as changé la batterie et tu l’as testée sur une autre Switch donc le problème de la décharge est résolue. Maintenant, si en la remettant dans l’autre console, tu as le même problème, soit il y a un problème hardware et quelque chose est défectueux, soit ce mode autoRCM est toujours actif. Pas de raison que cela ne fonctionne pas si c’est opérationnel sur l’autre console. De plus, tu pouvais aussi tester l’autre batterie sur la console hackée et le démarrage se serait fait en fonction ou non de ce mode autoRCM également.
Il se pourrait donc qu’un problème hardware soit autre.

Pour ce qui est de la reconnaissance USB sur PC, essaie de desinstaller et réinstaller le driver de la console sur ton PC. Attention, ce n’est pas le même driver en mode RCM et en mode normal. Le soft TegraRCMGui propose l’installatIon de ce driver en mode RCM. Et si tu n’as toujours pas de son, soit comme déjà dit, tu as un problème hardware, soit ton port USB ne fait pas le taff. Si cela avait été le câble, tu n’aurais pas pu injecter Hekate donc j’élimine cette piste mais tu peux toujours tester un autre câble sur un autre port USB. Ce qui est bizarre, c’est que ton dock prend en charge la console donc ce n’est pas le port USB de la console. Une autre piste que j’élimine.

En principe, la console démarre normalement après un hard reboot (power min 12s). Si ce n’est pas le cas, il y a un aspect qui m'échappe si ce mode autoRCM est bien désactivé. Fais cela sans la SD également.

Si après tout cela, tu as toujours le même problème, la piste hardware est à privilégier. Et dans ce cas, je ne vois pas la cause.

Quelle version de HOS ? Si mise à jour, les outils sont-ils à jour sur la SD ? Installation et réinstallation du driver sur PC ? Mode autoRCM vraiment désactivé ? Sinon la console attend de booter sans le JIG sur le CFW ? Câble USB défectueux ou pas le bon ? Port USB à changer sur PC ? Ou un problème hardware sur la console hack.

De multiples possibilités à vérifier d’après ce que tu décris.

Donc ton problème s’orienterait bien vers une corruption de BOOT 0.

Tu confonds création d’emuNAND et sauvegarde de NAND. L’un n’est pas l’autre mais les deux sont conseillés avant de modifier sa console. L'étape de la sauvegarde de NAND se fait au début du hack et cela permet en cas de problème de restaurer. La création d’emuNAND permet de se prémunir d’un ban mais également de protéger sa console de tout problème. Ainsi les aspects underground se font sur l’emuNAND et laisse la sysNAND propre. Les deux sont déliées. La sysNAND est la NAND système sur ta console et l’emuNAND est la NAND système « émulée » sur la SD.

Le Hack prévoit un certain nombre de précautions et des préconisations à suivre. C’est bien là le problème de beaucoup qui survolent les tutoriels complets ou qui suivent d’autres incomplets. Dans ton cas, les erreurs décrites depuis le début impliquent qu’il y a eu un problème en utilisant ChoiDujourNX pour mettre à jour et cela a dû corrompre le BOOT 0 et sans doute le BOOT 1 également.

Le fait de les restaurer suffit en principe mais encore faut-il que leur sauvegarde soit faite avant de les corrompre. C’est la piste à suivre dans ce cas. Et si tu avais eu une NAND sauvegardée, cela aurait permis de restaurer ton système proprement et de le mettre à jour HOS ensuite.

En revanche, les erreurs de package sont diverses. Soit elles concernent des éléments manquants sur la SD, soit cette dernière est corrompue.

Je ne peux pas être plus précis que cela. Ou alors des éléments m'échappent dans tes explications.

Tu as une sauvegarde des BOOT mais pas de la NAND, bizarre tout ça ou des éléments m’échappent. En faisant l’un, pourquoi ne pas avoir fait l’autre lorsqu’il le fallait. Ou alors, cela n’a pas été fait avant et tu l’as fait récemment mais si le BOOT est corrompu, cela ne sert pas à grand chose du coup.

En revanche si la console démarre normalement sans le hack, c’est qu’il ne s’agit pas d’une corruption de BOOT. Et dans ce cas, c’est que le problème vient soit de la SD, soit d’éléments manquant sur la SD.

Comme je ne suis pas devant ta console, difficile de savoir ce qui bloque réellement et à quel niveau quelque chose ne va pas. Je ne suppose que les aspects en fonction de ce que tu indiques. Les erreurs d’eFuses et de package comme indiqué sont là suite logique des indications déjà données.

Je ne vois pas ce que je pourrais donner comme autres indications dans les problèmes que tu rencontres.

Déjà si tu es en autoRCM et que tu n’as pas démarré ta console normalement, il y a des chances pour que tu aies encore conservé tes eFuses de la CM. Si ce n’est pas le cas, alors, ils sont grillés. S’ils ne sont pas grillés, le downgrade vers HOS 11.0.0 peut s’envisager pour réutiliser SX OS mais il y aura un problème avec le port cartouche puisque tu auras grillé les eFuses LOTUS. Aucun moyen de contourner cela via SX OS. Pour cela, il suffit de passer par le Hack Atmosphère/Hekate et utiliser DayBreak pour installer le firmware. Ceci est dans l'éventualité de ne pas les avoir grillés et sous réserve que tu puisses démarré le hack.

Ensuite, il te faut préparer ta SD correctement comme je l’ai déjà dit et éventuellement dumper les keys via Lockpick_RCM pour voir si cela règle ton problème de clés. Bizarre car Hekate n’en a pas besoin en principe. Mais à voir au cas où.

Je t’ai donné le lien du tutoriel pour le hack Atmosphère/Hekate qui apporte toutes les démarches et explications. Ceci est à lire et à suivre.

Et pour finir, une fois que tu auras suivi la démarche, et que tu arrives à booter, c’est que c’est bon. Si ce n’est pas le cas, et que tu as toujours un message de corruption de BOOT 0, il faudra le restaurer via Hekate tout simplement. De moi, cela ne semble pas être le cas puisque l’autoRCM est actif mais je n'affirme rien. Il te faudrait déjà suivre les indications du tutoriel pour utiliser Atmosphère/Hekate et voir ensuite.

Pour le moment, ne pas désactiver le mode autoRCM sinon les chances de downgrade vont devenir complexe. Et si c’est une corruption de BOOT 0, le fait d’avoir sauvegardé est déjà pas mal. La restauration s’opère via Hekate et cela reste simple. Avant d’envisager quoi que ce soit, suivre les indications précédentes.

Je ne parle d’une restauration d’usine car cela n'enlève pas toutes les traces du hack et dans ton cas, ce n’est pas vraiment nécessaire. De plus, cette restauration d’usine s'opère sur la syNAND et tes backups, ainsi que le hack, tu utilises ton emuNAND. J’ose espérer que ce soit le cas dans tous les cas car si tu utilises les aspects underground sur la sysNAND, ce n’est pas vraiment conseillé. Et comme dit, une restauration d’usine que propose la console n’efface pas les traces de hack sur la sysNAND, notamment la télémétrie, mais ceci était pour l’explication afin d’informer.

Pour ce que j’indique juste avant et qui concerne ton jeu, on parle d’agir sur les données du dit jeu qui auraient pu laisser des traces persistantes après toutes les manipulations faites. Du coup passer par un gestionnaire de backups qui le propose, comme tinfoil ou autre, permettrait d’effacer le ticket du jeu qui reste après désinstallation et autres éléments comme indiqué. C’est une solution possible.

Si après cela, tu as toujours un problème, il faudrait connaître le code erreur pour envisager d’autres pistes. Et voir également, si les derniers sigpatches sont en place. Les liens dans le tutoriel proposent les derniers mais peut-être que pour certains jeux, cela ne fonctionne pas. En revanche, ce serait bizarre car si ton jeu était opérationnel, aucune raison que cela ne soit pas le cas maintenant. Donc les pistes, juste avant, sont à vérifier.

Pour la 1re demande, si tu a supprimé le ticket du/des jeux en question, c’est qu’il y avait bien des traces. Pour le dossier que tu indiques, difficile de savoir si ce sont réellement des tickets inutilisés car je ne sais pas ce que tu as fait sur ta console. Toutefois, si tu en es vraiment certain, oui, tu peux supprimer. Et si tu as un doute, il faudrait savoir à quoi chacun correspond en fonction de ce que tu as installé ou non.

Comme tu as migré sous Atmosphère, il manque des éléments d’explicatIon ou plutôt des compléments, as-tu migré ton emuNAND ou seulement procédé à un changement de Hack ?

Je pose cette question car, en regardant ton Hekate_ipl.ini, il manque l'accès a l’emuNAND ou alors je fais erreur. Je n’ai pas testé la migration d’emuNAND de SX OS à Atmosphère via Hekate donc c’est plus une question qu’une affirmation.

En principe, la configuration du fichier Hekate_ipl.ini correspond plus à cela lorsqu’il y a la présence d’une emuNAND et que l’on passe par Hekate pour booter.

Code: Select All Code

[config]
autoboot=0
autoboot_list=0
bootwait=0
autohosoff=0
autonogc=1
updater2p=1
backlight=100

[CFW - sysMMC]
fss0=atmosphere/fusee-secondary.bin
kip1patch=nosigchk
atmosphere=1
emummc_force_disable=1
icon=bootloader/res/icon_payload.bmp

[CFW - emuMMC]
fss0=atmosphere/fusee-secondary.bin
kip1patch=nosigchk
emummcforce=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp

[Stock - sysMMC]
fss0=atmosphere/fusee-secondary.bin
emummc_force_disable=1
stock=1
icon=bootloader/res/icon_switch.bmp


Toutefois, il existe des configurations à souhait via ce fichier mais celle d’origine est semblable à celle-ci. En revanche, dans le cas d’une migration d’emuNAND, je ne sais pas, d’où ma question. Et cela dépend aussi de comment tu as décidé de booter, via Atmosphère ou Hekate.

Maintenant si tu n’as pas d’emuNAND et que tu utilises seulement la sysNAND, alors, la question ne se pose pas. Même si cela n’est pas trop recommandé, chacun fait comme il le souhaite.

Voici le lien du tutoriel pour Atmosphère/Hekate:
https://gamergen.com/forums/underground ... 36600.html
Cela t’apportera des infos complémentaires.

Et si tu n’as pas d’emuNAND, alors le passage de SX OS à Atmosphère se fait simplement. Il y a juste à préparer sa SD avec tous les éléments nécessaires. En revanche, si tu possédais une emuNAND sous SX OS, il faut réaliser une opération de migration au préalable pour la rendre compatible pour Atmosphère. Cela peut se faire via Hekate ou manuellement. Cela dépend surtout de ta configuration de l’emuNAND car via Fichiers ou via Partition, ce n’est pas la même opération. Et il n’y a pas de tutoriel détaillé sur le forum car trop de configuration possible.

Si tu as des problèmes via Atmosphère/Hekate, c’est qu’il doit manquer des aspects dans ton utilisation. A voir, car comme dit, je ne suis pas devant ta console.

sous tinfoil j'ai viré les tickets mais peut-être qu'il me faut passer par une autre application ?
Sous Goldleaf, j'ai un répertoire plein de "tickets inutilisés", dois-je les supprimer ?

Au passage, je pose une question HS :
ça fait deux fois que cela me fait la même chose : le soir je mets ma console en veille.
et le lendemain, elle est tiède et je suis obligé de faire un hard reset car pas d'affichage ... une idée ?
Je n'avais pas ça avant le passage sous atmo.

INFO : je suis passe par HEKAKE et le sx pro pour lancer le hack
Voici mon Hekake.ini d'ailleurs :

[config]
autoboot=0
autoboot_list=0
bootwait=3
backlight=100
autohosoff=0
autonogc=1
updater2p=0
bootprotect=0

[Atmosphere CFW]
payload=bootloader/payloads/fusee-primary.bin
icon=bootloader/res/icon_payload.bmp
kip1patch=nosigchk

[Stock SysNAND]
fss0=atmosphere/fusee-secondary.bin
stock=1
emummc_force_disable=1
icon=bootloader/res/icon_switch.bmp

Dans la mesure où elle est patchée et que tu es en 12.1.0, Pegascape ne pourra être utilisé ni cette méthode de hack.

Il te faudra passer par une puce pour procéder au hack de ta console. Aucune info ne sera donnée sur le forum pour cela. Je t’invite à consulter GBATemp ou autre site pour connaître et obtenir les infos à ce sujet.